Network ring topologies are gaining in popularity, particularly in Internet Protocol (IP) networks. Such networks enable carriers to offer large bandwidth to users in a cost-effective manner. They also lend themselves to fast rerouting in the event of network failures, since two alternative routes—clockwise and counterclockwise—are generally available for connecting any two nodes on the ring. A drawback of traditional ring implementations, such as SONET/SDH, is that ordinarily half of the available bandwidth in these rings must be reserved for fault protection and is not exploited under normal operating conditions. Some recently-developed protocols, however, provide more efficient bandwidth utilization by enabling data to be transferred between any pair of nodes in either direction around the ring, while maintaining fast protection against faults.
By way of illustration, FIG. 1 is a block diagram that schematically shows a bidirectional packet ring network 20, as is known in the art. Network 20 comprises a plurality of nodes 22, labeled N1 through N5, which are mutually connected by a bidirectional communication medium, such as optical fibers or conductive wires. The nodes typically comprise switching equipment, and may serve as either gateways to other networks (aggregation points) or access points. The communication medium is configured to define an inner ring 26, over which packets are conveyed between the nodes in a clockwise direction, and an outer ring 28, over which the packets are conveyed in a counterclockwise direction. It will be understood that the terms “inner” and “outer,” as well as “clockwise” and “counterclockwise,” are used arbitrarily in the context of the present patent application and in the claims, to distinguish between the two opposing directions of packet flow in a ring network. These terms are chosen solely for convenience of explanation, and do not necessarily bear any relation to the physical characteristics of the network.
In a SONET/SDH network, one of rings 26 and 28 is designated as the active ring, while the other ring remains on standby for fault protection when needed. Thus, at any given time, all of nodes 22 transmit and receive data only on the active ring. Communication interfaces in the nodes need not be capable of handling traffic at a rate any higher than the maximum data rate of one of the rings.
Bidirectional protocols, on the other hand, allow nodes 22 to communicate with one another over either ring 26 or 28. An example of such a protocol is the Resilient Packet Rings (RPR) protocol, which is in the process of being defined as IEEE standard 802.17. Network-layer routing over RPR is described, for example, by Jogalekar et al., in “IP over Resilient Packet Rings” (Internet Draft draft-jogalekar-iporpr-00), and by Herrera et al., in “A Framework for IP over Packet Transport Rings” (Internet Draft draft-ietf-ipoptr-framework-00). A proposed solution for Media Access Control (MAC—protocol layer 2) in bidirectional ring networks is the Spatial Reuse Protocol (SRP), which is described by Tsiang et al., in Request for Comments (RFC) 2892 of the Internet Engineering Task Force (IETF). These documents, which are available at www.ietf.org, are incorporated herein by reference. Using protocols such as these, each node in network 20 can communicate directly with all other nodes through either ring 26 or 28, using the appropriate MAC addresses of the nodes. RPR and SRP allow nodes to choose whether to route their packets on the inner or the outer ring, but do not provide any method for nodes to use in deciding which ring to choose.
SRP also defines a mechanism to be used by nodes on the ring in learning the ring topology. In the topology discovery phase of network start-up, described in section 4.6 of RFC 2892, each node can send out topology packets on one or both rings. The packet hops around the ring from node to node. Each node appends to the packet its own MAC address binding and other information. Eventually the packet comes back to the originating node, which uses the information that has been appended by the other nodes to build a topology map of the ring.
FIGS. 2A and 2B are block diagrams that schematically illustrate details of nodes 22 that are used in network 20, based on the RPR protocol described above. Node 22 comprises a RPR block 30, connected to transmit and receive data over both of rings 26 and 28. Block 30 is responsible for ring management and performs the MAC-layer functions of capturing packets that are addressed to node 22 on either ring, while passing all other traffic through to the next node along the ring. Node 22 typically has one MAC address on ring 26 and another on ring 28, to which packets may be sent by the other nodes. Alternatively, a single MAC address may be used for both rings.
When RPR block 30 captures a packet addressed to node 22, it delivers the packet to a traffic processing block 32 or 34 of the node. This block is typically implemented as a network processor chip that is able to access higher-layer protocol headers at wire speed (to avoid bottlenecks). It is responsible for network-layer functions, such as IP processing, and optionally other higher-level functions, as well, such as Quality of Service (QoS) and network security. In a node that serves as an access point, for example, block 32 or 34 is typically responsible for delivery of packets to users who are connected to network 20 through the node.
Normally, most of the packets arriving at RPR block 30 on rings 26 and 28 are passed through to the next node, so that the data rate required of traffic processing blocks 32 and 34 is considerably less than the maximum data rate of the network. The maximum data rate on each of the rings is identified in FIGS. 2A and 2B as “X”. It may occur at certain times, however, that a given node 22 will receive traffic at the full rate X on one or both of the rings. To deal with this situation, node 22 must have a traffic processing capacity of rate 2X. This capacity is achieved in FIG. 2A by providing two traffic processing blocks 32, each with an operating rate of X. RPR block 30 passes incoming packets on ring 26 to the traffic processing block shown on the right side in the figure, and incoming packets on ring 28 to the traffic processing block on the left side. An interface between the two traffic processing blocks can be used when interconnection is required. Alternatively, in the implementation shown in FIG. 2B, a single traffic processing block 34 with two rate X interfaces is used.
The dual, high-rate interfaces and traffic processing circuitry required in nodes 22, as shown in FIGS. 2A and 2B, contribute substantially to the cost, complication and power consumption of the nodes. These costs become ever more significant as the speed of network 20 increases. Furthermore, most of this high-speed capacity is wasted most of the time, since normally a given node consumes only a small portion of the total ring bandwidth.